home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-pppext-x25-01.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
12KB
|
443 lines
Network Working Group W A Simpson
Internet Draft Daydreamer
expires in six months July 1993
PPP in X.25
Status of this Memo
This document is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ietf-ppp@ucdavis.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of X.25 for framing PPP encapsulated
datagrams.
Simpson expires in six months [Page i]
DRAFT PPP in X.25 July 1993
1. Introduction
CCITT recommendation X.25 [2] describes a network layer protocol
providing error-free, sequenced, flow controlled, virtual circuits.
X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
and 6256. The capabilities that are provided by X.25 are considered
unnecessary and overly complex.
PPP also uses ISO 3309 HDLC as a basis for its framing [3].
At one time, it had been hoped that PPP HDLC frames and X.25 frames
would co-exist on the same links. Equipment could gradually be
converted to PPP. Subsequently, it has been learned that some
switches actually remove the X.25 header, transport packets to
another switch using a different protocol such as Frame Relay, and
reconstruct the X.25 header at the final hop. Co-existance and
gradual migration are precluded.
There are still ISO-lated pockets of existing X.25 links, and some
interest in bringing the advantages of the PPP multiprotocol datagram
service to this venue.
When X.25 is configured as a point-to-point circuit, PPP can use X.25
as a framing mechanism, ignoring its other features. This is
equivalent to the technique used to carry SNAP headers over X.25.
Simpson expires in six months [Page 1]
DRAFT PPP in X.25 July 1993
2. The Data Link Layer
This specification uses the principles, terminology, and frame
structure of the "Multiprotocol Interconnect on X.25 and ISDN in the
Packet Mode" [4].
The purpose of this specification is not to document what is already
standardized in [4]. Instead, this document attempts to give a
concise summary and point out specific options and features used by
PPP.
2.1. Frame Format
Since both PPP and X.25 use ISO 3309 as a basis for framing, the full
X.25 header is easily substituted for the smaller HDLC header. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control |D|Q| SVC# (hi) | SVC# (lo) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|p(r) |M|p(s) |0| NLPID(0xcf) | PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NLPID
This field contains a one octet Network Layer Protocol Identifier
(NLPID), which identifies the network layer protocol encapsulated
over the X.25 virtual circuit, in accordance with the Subsequent
Protocol Identifier (SPI) in ISO/IEC TR 9577 [5]. The value used
for PPP is <TBD> CF hex.
Protocol Field
The Protocol field is two octets and its value identifies the
protocol encapsulated in the Information field of the frame. The
field is transmitted and received most significant octet first.
2.2. Modification of the Basic Frame
The Link Control Protocol can negotiate modifications to the basic
frame structure. However, modified frames will always be clearly
Simpson expires in six months [Page 2]
DRAFT PPP in X.25 July 1993
distinguishable from standard frames.
Address-and-Control-Field-Compression
Because the Address and Control field values are not constant, and
are modified as the frame is transported by the network switching
fabric, Address-and-Control-Field-Compression MUST NOT be
negotiated.
Protocol-Field-Compression
When Protocol-Field-Compression is negotiated, both the NLPID and
Protocol fields are compressed.
On transmission, when the Protocol field is compressed to a single
octet, the NLPID is omitted.
On reception, the NLPID field is examined. If it is not the PPP
NLPID value, then it is expected to be a valid PPP Protocol value.
The Protocol field value 0x00cf is not allowed (reserved) to avoid
ambiguity when Protocol-Field-Compression is enabled.
3. In-Band Frame Format Detection
For Permanent Virtual Circuits (PVCs), the NLPID and PPP Protocol
fields easily distinguish the PPP encapsulation.
Initial LCP packets contain the sequence cf-c0-21 following the
header. When a PPP LCP Configure-Request packet is received, the
link enters Link Establishment phase.
Older implementations might contain the NLPID value CC hex, which is
used for IP. Other ISO conformant implementations might contain
other NLPID values, such as 80 hex (SNAP), or 81 hex (CLNP). Such
values indicate that the link is not properly configured for PPP
operation.
4. Out-of-Band signaling
Support for Switched Virtual Circuit (SVC) call setup and clearing is
not required.
The first octet in the Call User Data (CUD) Field (the first data
octet in the Call Request packet) is used for protocol
demultiplexing, in accordance with the Subsequent Protocol Identifier
Simpson expires in six months [Page 3]
DRAFT PPP in X.25 July 1993
(SPI) in ISO/IEC TR 9577 [5]. This field contains a one octet
Network Layer Protocol Identifier (NLPID), which identifies the
network layer protocol encapsulated over the X.25 virtual circuit.
The CUD field MAY contain more than one octet of information, and
receivers MUST ignore all extraneous octets in the field.
The PPP encapsulation MUST be indicated by a value of CF hex. Other
values of the CUD are beyond the scope of this specification.
5. Configuration Details
The accidental connection of a link to feed an X.25 multipoint
network SHOULD result in a misconfiguration indication.
The following Configuration Options are recommended:
Magic Number
Link Quality Monitoring
Protocol Field Compression
The standard LCP configuration defaults apply to X.25 links, except
MRU.
To ensure interoperability with existing X.25 implementations, the
default Maximum-Receive-Unit (MRU) is 1600 octets [4]. The basic
HDLC header is significantly shorter than the full-sized X.25 header,
which may give additional leeway in buffer management.
The typical network feeding the link is likely to have a MRU of
either 1500, or 2048 or greater. To avoid fragmentation, the
Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
exceed 1500, unless a peer MRU of 2048 or greater is specifically
negotiated.
The X.25 packet size is not directly related to the MRU. Instead,
Protocol Data Units (PDUs) are sent as X.25 "complete packet
sequences". That is, PDUs begin on X.25 data packet boundaries and
the M bit ("more data") is used to fragment PDUs that are larger than
one X.25 data packet in length.
Simpson expires in six months [Page 4]
DRAFT PPP in X.25 July 1993
Security Considerations
Security issues are not discussed in this memo.
References
[1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
progress.
[2] CCITT Recommendation X.25, "Interface Between Data Terminal
Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
for Terminals Operating in the Packet Mode on Public Data
Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.
[3] Simpson, W. A., "PPP HDLC Framing", work in progress.
[4] Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect
on X.25 and ISDN in the Packet Mode", RFC 1356, August 1992.
[5] ISO/IEC TR 9577, "Information technology - Telecommunications
and Information exchange between systems - Protocol
Identification in the network layer", 1990 (E) 1990-10-15.
Acknowledgments
This design was inspired by the paper "Parameter Negotiation for the
Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
University of California, Berkeley, 1992, unpublished.
Simpson expires in six months [Page 5]
DRAFT PPP in X.25 July 1993
Chair's Address
The working group can be contacted via the current chair:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California, 93111
EMail: fbaker@acc.com
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6205
EMail: Bill.Simpson@um.cc.umich.edu
Simpson expires in six months [Page 6]
DRAFT PPP in X.25 July 1993
Table of Contents
1. Introduction .......................................... 1
2. The Data Link Layer ................................... 2
2.1 Frame Format .................................... 2
2.2 Modification of the Basic Frame ................. 2
3. In-Band Frame Format Detection ........................ 3
4. Out-of-Band signaling ................................. 3
5. Configuration Details ................................. 4
SECURITY CONSIDERATIONS ...................................... 5
REFERENCES ................................................... 5
ACKNOWLEDGEMENTS ............................................. 5
CHAIR'S ADDRESS .............................................. 6
AUTHOR'S ADDRESS ............................................. 6